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Description 

[0001] This invention relates to a method am -iparatus for linking software programs and, more specifically, to a 
method and apparatus for providing a dynamic mg system to manage changes in successive versions of a software 
program. 

[0002] Software development is an on-going process. A first version of software may be adequate for a task at the 
time the software is written, but may need upgrading as time goes by and additional features are added. The software 
development process is especially problematic when a software application binds to shared objects (also called "li- 
braries"). When a shared object is updated or changed, the interface to the shared object is often updated or changed 
as well. In addition, it is often the case that, even if the interface to a shared object does not change, some portion of 
the function performed by the shared object changes. 

[0003] Some conventional systems dynamically link application software programs to shared objects at runtime, In 
such systems, an application software program that accesses a shared object must be carefully checked every time 
a new version of the shared object is released. The application software program must be checked to determine that 
it does not use an interface to the shared object that no longer exists in the new version of the shared object The 
application software program also must be checked to determine that the operation of the shared object has not changed 
(even if the interface to the shared object remains the same). 

[0004] Conventionally, this checking often is done by a human being Errors caused by mismatched interfaces are 
often discovered only during execution of the application software program when an interface mismatch is found or 
when a shared object does not function the way it used to. What is needed is a way of determining which version of a 
shared object a particular application software program "expects" to link to and a way of checking whetherthe expected 
version of the shared object is present during dynamic linking at runtime. 

[0005] Conventionally, the filename of the shared object itself is updated for each new version. Thus, only a most 
recent version of the shared object is present during linking and the most recent version has a completely different 
filename from an older version of the object. It would be desirable to avoid renaming an object each time a new version 
of the object is created. 

[0006] Conventional systems often try to avoid version checking by releasing application programs and shared ob- 
jects (libraries) as a "whole system," i.e., a new application is shipped with all of its needed shared objects, regardless 
of whether there has been any change between versions of the shared objects. It would be desirable to be able to 
upgrade only those parts of the system that are necessary to accommodate a change. 

[0007] WO-A-94/25918 describes a method and an apparatus for providing versioning information in a software 
program. In WO-A-94/2591 8, however, it is not disclosed where the version name for the versioned object code comes 
from, thereby not disclosing a method or a facility for a version management. 

[0008] The present invention provides a method according to claim 1 and an apparatus according to claim 11 for 
dynamically linking software programs. The invention provides a versioning system to keep track of changes in suc- 
cessive versions of objects accessed by application software programs. The invention checks the interfaces used by 
the application software program to access versioned objects and detects attempts by the application software program 
to access an invalid version of the versioned object. The present invention, thus, allows for a controlled evolution of 
objects, while maintaining backward compatibility between application programs and objects. 
[0009] The invention provides a versioning system that allows symbolic interfaces and implementation changes to 
be labelled within an object. At build time, a link-editor adds data to a versioned object defining all available versions 
of the object (a version definition section and a version symbol section). At build time the link-editor adds data to the 
software application defining the version requirements of the application (a version dependency section). At runtime, 
a runtime linker verifies that the requirements of the software application match the version definition stored in the 
objects themselves, i.e., that the versioned object needed by the software application is available to the runtime linker. 
[0010] A version is a name or label recorded in an object. A version may be associated with one or more global 
symbols - in which case it defines a symbolic interface. Otherwise, a version can simply be an indicator of an imple- 
mentation change, i.e., of a change in which the functionality of an object changes, but no new global symbols are 
defined. In this latter case, the version is termed a "weak" version. In the described embodiment of the invention, the 
global symbols and version names associated with each version are defined in a "mapfile" generated by a human 
being. The mapfile is input to the link-editor at build time along with one, or more, relocatable (compiled) objects to 
create a versioned object, By default, at build time, when an application is link-edited with a versioned object that 
contains versioning information, a dependency is established in the application to those versions that include the global 
symbols referenced by the application. In addition, a "weak" dependency is established to any weak definitions. 
[001 1 ] The present invention allows inheritance of version definitions within an object. Versions inherit versions and, 
thus, symbol sets can be combined to produce interrelated interface definitions. For example, a new version might 
inherit all of the global symbols of an older version. The present invention can control the visibility of an object's versions 
during a link-edit, in effect controlling those interfaces available to the application program. The present invention also 
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can force the application software program to require a weak version of an object. 

[0012] As described herein, the present invention is a method for providing versioning information in a software 
program, comprising the steps of: providing first object code for a first software program; providing a mapfile specifying 
a version name associated with a version of the first software program; and linking the first object code, so that an 
addition is made to the first object code, in accordance with the mapfile, of information defining the version name of 
the version of the first software program, to yield a versioned object. 

[0013] As described herein, the present invention is an apparatus for providing versioning information in a software 
program, according to claim 11 . 

[0014] As described herein, the present invention is a computer program product, according to claim 1 7. 

[0015] Various advantages of the present invention will become more fully apparent when the following detailed 

descriptions of the invention are read in conjunction with the accompanying drawings. 

[0016] The invention will now be described with reference to the accompanying drawings, wherein: 

Fig. 1 is a block diagram of a computer system in accordance with the present invention. 

Figs. 2(a), 2(b), and 2(c) are diagrams showing inputs and outputs of a link-editor program of Fig. 1 at build time. 

Fig. 2(d) is a diagram showing inputs and outputs of a runtime-linker program of Fig. 1 at runtime. 

Figs. 3(a) and 3(b) are flow charts showing steps performed by the link-editor of Fig. 2(a) to add a version definition 

section and a version symbol section to an object. 

Fig. 4 shows a format of a mapfile of Fig. 2(a). 

Fig. 5 shows an output of the link-editor of Fig. 2(a) that is included in a versioned object. 
Fig. 6 shows a format of a version definition section of Fig. 5. 
Fig. 7 shows a format of a version symbol section of Fig. 5. 

Fig. 8 is a flow chart showing steps performed by the link-editor of Fig. 2(b) or 2(c) to add a version dependency 
section to a dynamic executable application program. 
Fig. 9 shows a format of a mapfile of Fig. 2(c). 

Fig. 10 shows an output of the link-editor of Fig. 2(b) that is included in a dynamical executable application program. 
Fig. 11 shows a format of a version dependency section of Figs. 5 and 10. 
Fig. 12 shows a format of a header section of Figs. 6, 7, and 11. 
Fig. 13 is a listing of values in the header of Fig. 12. 
Fig. 14 is a listing of values in the header of Fig. 12. 

Fig. 15 is a flow chart of steps performed by the runtime linker of Fig. 2(d) to verify that the version requirements 
of a application program match the versions present in an object being linked to the application program. 
Fig. 16 is an example of a version definition section added to an object by the link-editor. 
Fig. 17 is an example of a version symbol section added to an object by the link-editor. 

Fig. 1 8 is an example of a version dependency section, which can be added to either or both of a versioned object 
or a dynamic executable application program by the link-editor. 

DETAILED DESCRIPITON OF THE PREFERRED EMBODIMENTS 

[0017] The following description is of the best presently contemplated mode of carrying out the invention. This de- 
scription is made for the purpose of illustrating the general principles of the invention and is not to be taken in a limiting 

1. General Discussion 

[0018] Fig. 1 is a block diagram of a computer system 100 in accordance with the present invention. Computer 
system 1 00 includes a CPU 1 02, a memory 1 04, and input/output lines 1 06. It will be understood by a person of ordinary 
skill in the art that computer system 1 00 can also include numerous elements not shown in the Figure for the sake of 
clarity, such as disk drives, keyboards, display devices, network connections, additional memory, additional CPUs, etc. 
[0019] Memory 104 includes a library (libc) (also called a shared object) 114, source code 110 and relocatable (com- 
piled) code 112 of shared object 114. Memory 104 further includes source code116foran application software program, 
relocatable (compiled) code 118 for application 116, and dynamic executable (linked) code 120 for application 116. 
Memory 104 further includes OS (kernel) software 122, mapfiles 130 and 132, a link-editor 124, and a runtime-linker 
1 26. Each of shared object 1 1 4 and dynamic executable object 1 20 is created by link-editor 1 24. Each of shared object 
114 and executable object 120 has an Executable Linking Format (ELF) similar to the ELF defined in "System V Ap- 
plication Binary Interface," third edition, published by Prentice Hall, Inc. 

[0020] In the present invention, however, the ELF format of objects 114 and 120 has been augmented to include 
additional data, as described below. Shared object 114 has a format shown in Fig. 5. Dynamic executable object 120 
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has a format shown in Fig. 10. Shared object 114 includes versioning information (aversion definition section) for each 
version of the shared object and a list of public symbols for each version (a version symbol section) as discussed 
below. Shared object 114 also may contain information concerning version dependencies (a version dependency sec- 
tion). Executable object 120 contains information concerning version dependencies (a version dependency section) 
5 as discussed below. A person of ordinary skill in the art will understand that memory 1 04 also contains additional 
information, such as application programs, operating systems, data, etc., which are not shown in the figure for the sake 
of clarity. 

[0021] A preferred embodiment of the invention runs under the Solaris operating system, Version 2.5. Solaris is a 
registered trademark of Sun Microsystems, Inc. Unix is a registered trademark in the United States and other countries, 

10 exclusively licensed through X/OPEN.Ltd. 

[0022] Fig. 2(a) is a diagram showing input and output of link-editor 124 of Fig. 1 . Fig. 2(a) shows the creation of a 
versioned shared object. Although the following discussion deals with versioning for shared objects, the present in- 
vention can also be employed to implement versioning in dynamic executable objects and in relocatable objects. Thus, 
these types of objects can also contain a version definition section and a version symbol Link-editor 1 24 receives input 

15 of mapfile 130 and of relocatable object code 112 for a shared object and generates an output of shared object 114. 
Mapfile 130 specifies the global symbols and a version name for each version of the shared object. In the described 
embodiment, mapfile 130 preferably has the format of Fig. 4 and is created by a human being. In other embodiments, 
mapfile 1 30 may be created by the compilation system. 

[0023] Fig. 2(b) shows additional input and output of link-editor 124 of Fig. 1 . Fig. 2(b) shows the link-editing of an 
so application program with the versioned shared object of Fig. 2(a). Link-editor 124 receives as input versioned shared 
object 114 and relocatable object 118. link-editor 124 processes relocatable object 118 and shared object 114 to gen- 
erate dynamic executable object 120. As shown in Fig. 2(c), a mapfile 132 also may be used in this step to indicate 
which versions of object 114 are allowed in this link procedure. Mapfile 132 preferably has the format of Fig. 9 and is 
created by a human being. 

25 [0024] As shown in Fig. 2(d), at runtime, runtime-linker 126 verifies that all versions of shared object 114 needed by 
dynamic executable 120 are present. If so, runtime linker 126 creates and executes a process file 122 to execute 
dynamic executable 1 20. Thus, link-editor 124 builds versioned shared objects from relocatable objects and determines 
which versions of the shared object are needed by an application program. Runtime-linker 126 maps the objects in its 
memory and binds them together. Thus, runtime-linker 1 26 simply puts objects together as directed by link-editor 124. 

so Runtime-linker 126 performs a verification check to insure that the version of shared object 114 required by dynamic 
executable 1 20 is present. If the correct version is not present, runtime-linker 1 26 generates an error. 
[0025] The following paragraphs discuss types of changes that can be made between various versions of shared 
object 114. In general, these changes can be categorized into two groups: compatible updates and incompatible up- 
dates. Compatible updates are additive, i.e., all previously available global symbols in the interface to shared object 

35 114 remain intact. An example of a compatible update is the addition of a global symbol. Because no symbols have 
been removed from previous versions, application software that interfaces with previous versions should still operate 
correctly. Incompatible updates change the existing interface to shared object 1 1 4 in such a way that existing applica- 
tions using the interface can fail or can behave incorrectly. Examples of incompatible updates include: the removal of 
a symbol, the addition of an argument to a function, the removal of an argument from a function, and a change in size 

40 or content of an argument to a function. Bug fixes to shared object 114 may be compatible or incompatible with an 
existing interface. For example, a compatible bug fix may merely alter the internal function of shared object 114 while 
maintaining the previously defined interface. An incompatible bug fix may require the alteration of the interface to 
shared object 114. 

45 2. Creating Versioning Information at Build Time 

[0026] The preceding paragraphs provide a general discussion of the processes performed at build time and at 
runtime to implement versioning in accordance with the present invention. The following paragraphs discusses how 
link-editor 124 adds versioning information to a shared object and to the application program. 

50 

a. Creating a Versioning Definition for Versioned Objects at Build-Time 

[0027] In a preferred embodiment, link-editor 1 24 controls versioning for shared objects in accordance with version 
directive information in mapfile 130, as discussed below. Mapfile 130 preferably is created by a human being, but also 
55 could be created by software such as a compilation system. 

[0028] Figs. 3(a) and 3(b) are flow charts showing steps performed by link-editor 124 of Fig. 2(a). These steps are 
part of the steps performed to create a versioned object, such as shared object 1 1 4. A person of ordinary skill in the 
art will understand that the steps of Figs. 3(a) and 3(b), (as well as the steps of Fig. 8) are performed by CPU 102 of 
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Fig. 1, executing instructions of link-editor 124 stored in memory 104 and using data structures stored, e.g., in memory 
104. 

[0029] As shown in step 302, the steps of Fig. 3(a) preferably are initiated when link-editor 1 24 is invoked with a -G 
option on a command line. The -G option indicates that linker-editor 124 should produce a shared object (as opposed 
to a dynamic executable bject). In a preferred embodiment of the present invention, link-editor 124 also is invoked with 
the -M option, which indicates that mapfile 130 should be used as a source of "version definition directives." The 
example of Fig. 2(a) shows creation of a shared object, but the present invention can also be used to create versioned 
relocatable objects and versioned dynamic executable objects. 

[0030] The following example does not include a detailed explanation of Unix commands used in the examples (cat, 
cc, pvs, Id). Unix commands arediscussed in, the Solaris Reference Manual, which is availablefrom Sun Microsystems. 
The following paragraphs discuss examples of shared object source code 1 1 0 and mapfile 1 30. Table 1 shows source 
code 110 for four source files ("foo.c", "data.c", "barl .c", and "bar2.c") that are written in the C programming language. 
The source files collectively form a shared object. The mapfile of Table 2 defines global interfaces for various versions 
of the shared object. These files are compiled to form relocatable object 11 2 of Fig. 1 . Thereafter, link-editor 1 24 creates 
a versioned shared object 114 in accordance with mapfile 130, as described below. 



$ cat foox 




extern const char * fool; 
extern const char * ~foo2; 




void fool() 

^ (void) printf(_fool); 






void f oo2() 

^ /-.~.*~4\ ~-i~itf 

^ iyoia) pnntt^toox); 






$ cat datax 




const char * jfool = "string use 
const char * _foo2 = "string use 


d by function foolQV; 


d by function foo20\n H ; 


.$ cat barl.c 




extern void fool(); 




void barlQ 




J foolO; 




$ cat bar2.c 




extern void foo2(); 




void bar2() 

} { foo20; 







55 

TABLE 1 (source code for shared object) 
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TABLE 2 (Mapfile defining versions of shared object) 



5 
10 


$ cat mapfile 
SUNW.1.1 { 

global: 

fool; 

local: 


#Release X 




}; 

SUNW.1.2{ 

global: 

foo2* 

} SUNW.1.1; 


#ReleaseX+l 


20 


SUNW.L2.1{ }SUNW.L2; 


#Release X+2 


25 


ct ixmr i i« r 
oUIN w.i~?a \ 

global: 

barl; 

} SUNW.1.2; 




30 


global: 

bar2; 

} SUNW.12; 


#Releace Y+3 

7TX\CKmuC A r J 


35 


SUNW.1.4 { 

global: 

bar3; 

} SUNW.Ua SUNW.lJb 




40 







[0031] Fig. 4 shows a format of mapfile 130 using Backus-Naur format. In Backus-Naur format, square brackets (" 
[" and "]") indicate an optional element. Thus, for example, in Fig. 4, "[version name]" is an optional element of the 
mapfile format. 

[0032] Shared object 114 provides global symbols to which other objects, such as dynamic executable 120, can bind 
50 at runtime. These global symbols are specified in mapfile 130 and describe an Application Binary Interface (ABI) of 
shared object 114. During the lifetime of shared object 114, the interface of an object can change due to the addition 
or deletion of global symbols. In addition, the evolution of shared object 1 1 4 may involve internal implementation chang- 
es to shared object 114 that do not affect the global symbols of the interface. 

[0033] Table 2 shows an example of mapfile 130. In Table 2, mapfile 130 contains version definitions for versions 
55 SUNW.1 .1 , SUNW.1 .2, SUNW.1 .2.1 , SUNW.1 .3a, SUNW.1 .3b, and SUNW.1 .4 of shared object 114. The version def- 
initions include all versions (and their global symbols) ever defined for shared object 114. In the example, SUNW.1.1 
is a version of shared object 114 contained in Release X; SUNW.1 .2 is a version of shared object 114 contained in 
Release X+1 , which inherits the global symbols of version SUNW.1 .1 . SUNW.1 .2.1 is a version of shared object 114 
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contained in Release X+2, which inherits the global symbols of version SUNW.1 .2. Note that SUNW.1 .2.1 is a "weak" 
version because it does not contain any new global symbols. This version indicates an "implementation" change in the 
shared object. The other versions indicate "interface" changes. SUNW.1 .2.1 represents a version having changes to 
the function of the shared object, but not to its interface. 

s [0034] SUNW.1 3a is a version of shared object 114 contained in Release X+3, which inherits the global symbols of 
version SUNW.1. 2. SUNW.1. 3b is also apart of Release X+3 and also inherits the global symbols of version SUNW. 
1.2. Version SUNW.1. 3b, however, defines the global symbol "bar2", instead of the global symbol "barl", which is 
defined in version SUNW.1 .3a. Version SUNW.1 .4 defines one global symbol "bar3" and also inherits the global symbols 
of both SUNW. 1.3a and SUNW. 1.3b. 

10 [0035] In the example of Table 2, the symbol "fool" is the only global symbol defined in the public interface of version 
SUNW.1 .1 . The special "auto-reduction" directive ("*") causes the reduction of all other global symbols of the shared 
object to have local scope so that they are not a part of the interface to the shared object. Thus, the public interface 
of shared object 114 for version SUNW.1 .1 consists of the internal version definition for that version, associated with 
the global symbol "fool". 

15 [0036] Table 3 shows unix commands to compile and link the source code files of Table 1 . The object codes files 
"foo.o", "data.o" "barl o", and "bar2.o" (not shown) are dynamically linked using mapfile 130 of Table 2 to produce a 
shared object 114 called "libfoo.so.1". (In this example, the cc compiler automatically calls the ld(1) link-editor 124.) 
The "-G" option on the command line indicates that link-editor 124 should produce a shared object, and not an exe- 
cutable object. The "In" command creates a "compilation environment" name suitable for the "-I" option of ld(1). The 

20 "pvs" Unix command prints out the versioning information forthe shared object created by link-editor 124 and the global 
symbols available for each version. 

[0037] As shown in Table 3, a "base version" definition is also created for the object. This base version is defined 
using the name of the shared object itself (e.g., "libfoo.so. 1 "), and is used to associate any reserved symbols generated 
by the link-editor 124 with the object. In the example of Table 3, for instance, a base version definition is created for 

25 the shared object libfool .so.1 that contains reserved global symbols created by the linker (e.g.,_etext, _edata, end, 
_DYNAMIC,_PROCEDURE_LINKAGE_TABLE_, and GLOBAL_OFFSET_TABLE).). 
TABLE 3 (creating a versioned shared object (at build-time) and displaying the version information) 
[0038] Returning to Fig. 3(a), if (in step 304) a version name appears in mapfile 1 30, link-editor 1 24 creates several 
sections within shared object 114 that specifically relate to versioning. The special sections are shown in Fig. 5 and 

30 include a version definition section 
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$ cc -o libfoo.so.l -M mapfile -G foo.c baric bar2x data.c 


5 


$ In -s libfoo.so.l libfoo.so 
$ pvs -dsv IibfoOiSo.1 
libfoo.so.1: 






~GLOBAL_OFFSETTABLE_; 




.DYNAMIC; 






_edata; 






.PROCEDURE.IJNKAGE.TABLEj 


15 


SUNW.1.1: 
fool; 

SUNW.1.1; 






SUNW.12: 


{SUNW.1.1}: 


20 


foo2; 

SUNW.12; 




SUNW.12.1 [WEAK]: 


{SUNW.12}; 




SUNW.12.1; 


25 


SUNW.Ua: 


{SUNW.12}; 




barl; 

SUNW.IJa; 






SUNW.Ub: 


{SUNW.1.2}; 




bar2; 




30 


SUNW.Ub; 






SUNW.1.4: 


{SUNW.13a 




SUNW.13b>; 




bar3; 




35 


SUNW.1.4; 





506, a version symbol section 508, and an optional version dependency section 51 0. The following paragraphs discuss 
the creation and use of these sections. 

40 [0039] Fig. 6 shows a format of version definition section 506 of versioned shared object 114. Fig. 16 shows an 
example of a version definition section based on Tables 1 -3. The section includes a section header 602 (see Fig. 12), 
a structure version 604, flags 606, a version definition index 610, a count value 612, a hash value 614, an aux value 
61 6, a next version definition pointer 61 8, the name of the version itself 620, and zero or more names of versions from 
which the defined version inherits global symbols 620, 622. 

45 [0040] Each shared object 114 includes a single version definition section 506, containing multiple version definitions. 
Each group of fields 604-622 is called a "version definition". The following paragraphs discuss the contents of a version 
definition. Section header 602 indicates the number of versions of the shared object contained in the version definition 
section. Each version definition section includes information for a base version that defines global symbols not explicitly 
defined in the mapfile. Thus, fields 604-622 (a "version definition") are created for a base version in step 306 of Fig, 3 

so (a). Field 609 ("base" flag) is set in this base version definition. 

[0041] As shown in step 308, a version definition (fields 604-622) is created by link-editor 124 for each version of 
shared object 114 defined in mapfile 130. Thus, for the mapfile 1 30 of Table 2, six version definitions in addition to the 
base version definition are created in step 308. Steps 310-316 of Fig. 3(b) are performed for each version definition 
created in Steps 306, 308. As shown in step 310, if mapfile 1 30 does not define any global symbols for a version (see, 

55 e.g., SUNW.1.2.1 of Table 1), the "weak" flag 608 for that version definition is set in step 31 2 (see Fig. 16). 

[0042] Version 604 is a version number of the structure itself. Version definition index 610 has a different (unique) 
value for each version defined for shared object 114 and will be discussed below in connection with Fig. 7. Count value 
61 2 refers to the number of instances of pairs of fields 620 and 622 in this version. Hash value 614 is a hash value to 
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the name of the version and uses a conventional ELF hashing function. Aux value 61 6 is an index to the first field 620 
for this version. Next version definition 61 8 is an index to field 604 of the next version definition in the version definition 
section. 

[0043] Step 31 3 creates an entry 620, 622 for the name of the current version and sets AUX to point to this entry. 
Thus, the first field 620 contains the version name of the version itself. 

[0044] Inheritance information consists of one or more version names from which the defined version inherits other 
versions. In step 314 of Fig. 3(b), if mapfile 130 includes inheritance information, as shown in Fig. 4 and Table 2. In 
step 316 link-editor 124 creates one or more entries 620 and 622 to hold inheritance information. Fields 620 and 622 
exist for each version from which a version inherits other versions. Field 620 includes the name of the inherited version 
definition and field 622 points to the next field 620 (or null). 

[0045] In step 318 of Fig. 3(a), link-editor 124 creates a version symbol section for all symbols of the object being 
link-edited. Fig. 7 shows a format of a version symbol section 508. It is important to note that the entries in version 
symbol section 508 correspond one-to-one with the symbols in the symbol table for the object (see Fig. 17). Symbol 
tables are familiar to persons of ordinary skill in the art and are also described in the System V Application Binary 
Interface Manual, and will not be described herein. The format of section header 702 is discussed in connection with 
Fig. 13. Each entry 704 in version symbol section 508 is an index of the corresponding version for which the symbol 
is defined. Thus, referring to Table 2, if version SUNW.1 3b has an index 610 of "6" (see Fig. 16), then the entry in the 
version symbol section corresponding to the global symbol "bar2" will contain an entry of "6" (see Fig. 1 7). As indicated 
in Fig. 7, entries for symbols having local scope contain a value of "0". Entries for symbols in a base version definition 
contain an entry of "1". As discussed above, only symbols explicitly defined as global symbols (e.g., symbols for the 
base section, the names of each version, "fool", "foo2", "barl", and "bar2", and "bar 3") have non-zero entries 704 in 
version symbol section 508. 

[0046] Step 320 of Fig. 3(a) creates a version dependency section for shared object 1 1 4 (if needed). For example, 
shared object 1 1 4 may reference other versioned objects. Creation of a version dependency section Is discussed below. 

b. Creation of Version Dependency Information at Build-Time 

[0047] Table 4 shows an example of a source version of application program software 116 ("prog.c"). "Prog.c" ref- 
erences two global symbols in shared object 114 libfoo.so.1, namely: "fool" and "foo2". These symbols are defined to 
be part of the interfaces SUNW.1 .1 and SUNW.1 .2, respectively. In Table 4, at build-time, compiler cc also initiates Id 
link-editor 124. At build time, a binding occurs between "prog.c" and versions "SUNW.1 .1 , SUNW.1 .2 and SUNW.1 .2.1 , 
which contains the global symbols "fool" and "foo2". The former two versions represent the symbol bindings. The latter 
is recorded due to its weak nature. Because no version control directives are specified by the compile/link command, 
link-editor 124 will check all versions of shared object 114 present when resolving global symbols in prog.c. 
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$ cat pro ' 
extern void foolO; 
extern void foo2Q; 



fool(); 
foo2(); 



$ ce -o prog progx -L. -R. -lfoo 
$ pvs -r prog 

libfoo.so.1 (SUNW.12 SUNW.12.1); 



TABLE 4 (Source code for an application program and linking 
to an object) 



[0048] Fig. 8 shows steps performed by link-editor 124 at build time to create dynamic executable ELF file 1 20 from 
relocatable object 1 1 8 and shared object 114. The format of dynamic executable ELF file 120 is shown in Fig. 1 0. The 
format of Fig. 10 is similar to that of Fig. 5, except that Fig. 10 contains a version dependency section, but no version 
definition section or version symbol section. Fig. 11 shows a format of version dependency section 510. 
[0049] In step 802 of Fig. 8, link-editor 124 determines whether the object being linked (e.g., prog) depends on other 
objects (e.g., libfool .so.1) by checking for unresolved global symbols in prog against the global symbol table of the 
other objects being linked. If so, in step 804, link-editor 1 24 determines whether the needed object has versions i.e., 
whether the needed object has a version definition section. If, in step 806, link-editor 124 determines that only certain 
versions of the needed object are visible lo link-editor 124, control passes to step 810. Otherwise, control passes to 
step 808. 

[0050] In step 808, link-editor 124 creates a version dependency section in dynamic executable 120 by looking at 
all available version definition sections of shared object 114 to determine which of these versions contains the global 
symbols required by relocatable object 118. Alternatively, mapfile 132 has identified only certain versions as being 
visible to link-editor 1 24. In step 81 0, link-editor 1 24 only looks at the visible version definition sections of shared object 
1 1 4 to determine which of these versions contains the global symbols required by relocatable object 1 1 8. This provision 
allows linking to be restricted to specific versions of shared object 114. 

[0051] The dependencies recorded in the version dependency section of Fig. 10 are created whenever an application 
program references a global symbol in the interface to a shared object. Table 4 shows an example of a source version 
of application program software 116 ("prog.c"). Application program "prog.c" references global symbols "fool", which 
is defined in version SUNW.1.1, and "foo2", which is defined in version SUNW.1.2 (see Table 2). Thus, a dependency 
exists between prog.c and SUNW.1.2 (which inherits from SUNW.1 .1). Link-editor 124 creates a version dependency 
section in the dynamic executable 120 of prog indicating that it depends on version SUNW.1.2 (see Fig. 18). For each 
undefined global symbol in relocatable 118, link-editor 124 obtains the information telling where (in which version) the 
symbol is located by looking at the version definition section and version symbol section of all shared objects that are 
being linked with relocatable 118. 

[0052] Fig. 11 shows a format for version dependency section 510. Version dependency section 510 includes a 
section header 1102, as described in connection with Fig. 12, a structure version 1 104, a count value 1106, afilename 
1 1 08, and aux value 1 1 1 0, a next version value 1 1 1 2, and a plurality of instances of fields 1 1 1 4-1 122. Fields 1 1 1 4-1 122 
include a hash value 1114, a "weak" flag 1116, an unused field 1118, a name field 1120, and a next name field 1122. 
[0053] Structure version value 1 1 04 is not related to the versioning of the present invention, as discussed above in 
connection with Fig. 6. Count value 1106 indicates a number of instances of fields 1114-1122. Filename 11 08 is a name 
of a shared object dependency. Aux value 1 1 1 0 is an index to the first field 1114 forthis version. Next version dependency 
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section value 1112 is an index to the next version field 1104 (or null). Each instance of fields 1114-1122 identifies a 
version that is required by the object being created. A version is required if it defines global symbols referenced by the 
object. At least one instance of fields 1114-1122 always exists. 

[0054] Hash value 1114 is generated from the name of the version 1120 and is generated using a conventional ELF 
hashing function. "Weak" flag 1116 indicates whether the version depended upon is a weak version, i.e., whether the 
version contains no global symbols. Field 1118 may not occur in all implementations of the invention and is included 
merely for alignment purposes. A first instance of name field 1120 contains a name of the version itself (e.g., "SUNW. 
1.2"). Next name field 1122 is a pointer to a next hash value 1114. 

[0055] A current implementation of the invention uses "version reduction", in which not all inheritances are recorded 
in version dependency section 510. Weak versions are recorded and needed version are recorded. When these ver- 
sions inherit global symbols from other versions, however, the other versions generally are not recorded. For example, 
inheritance from a first weak version though a second weak version preferably is reduced before being recorded in 
fields 920, 922. Similarly, inheritance from a first non-weak version though a second non-weak version preferably is 
reduced before being recorded. Inheritance between a weak and a non-weak version is not reduced. Thus, SUNW. 
1 .2 is recorded in fields 920, 922, but the inheritance from SUNW.1 .1 is not recorded. In addition, a dependency upon 
weak version SUNW.1. 2.1 is recorded. 

[0056] Figs. 12-14 show various aspects of the sections of Figs. 6, 7, and 11. Not all fields of Figs. 12-14 will be 
described herein, as many of these fields are part of the conventional ELF format. Only fields relevant to the present 
invention will be discussed. Fig. 1 2 shows a format of a section header used in section headers 602, 702, and 1102. 
An "sh_name" field 1202 holds a name of a section and an "sh_type" field 1204 holds a type of the section. Values 
1202 are particularly relevant to the present invention. Fig. 13 shows values indicating the various type values in field 
1204. Values 1302 are particularly relevant to the present invention. The section header format of Fig. 12 also includes 
an "sh_size" field 1 306, which indicates a number of bytes in the section, an "shjink" field 1 308, and an "shjnfo" field 
1310. Fig. 14 shows example values for the "sh type", "shjink", "shjnfo" fields. Values 1402 are particularly relevant 
to the present invention. 

[0057] The previous paragraphs discuss creation, at build time, of an ELF object 114 containing version definition 
section 506 and version symbol section 508, and further discuss creation of an ELF object 120 containing version 
dependency section 51 0. It should be understood that sections 506 and 508 are created only in objects containing 
definitions of global symbols and section 510 is created only in objects that depend on objects containing global sym- 
bols. Thus, a shared object having global interfaces will include sections 506 and 508 and possibly section 510. Exe- 
cutable application programs that reference the shared object will include section 51 0 only. 



$ cat mapffle 

libfocso - SUNW.1.1; 

$ cc -o prog prog.c -M mapffle -L -R. -Ifoo 
Undefined first referenced 

symbol in file 

foo2 prog.o (symbol belongs to \ 

unavailable version ./libfoo^o (SUNW.1.2)) 
Id: fatal: Symbol referencing errors. No output written to 
prog 



TABLE 5 (Linking using a mapfile to specify which version is 
legal" to link to) 



c. Restricting an Application's Build At Build Time 

[0058] The previous paragraphs discuss an example of version binding between a relocatable and all available ver- 
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sions of shared object 114. Binding can also be restricted to occur between an application program and only a particular 
version of an object. Fig. 9 shows a format of a file control di ve in the mapfile 132 of Fig. 2(c). A file control directive 
of this format is used to bind a dynamical executable obje accordance with a specific version of another object. 
As shown in Fig 2(c) and Table 5, if the link-editor is run with apfile 1 32 containing a file directive of the format shown 
in Fig. 9, then binding will occur only with the specified version of the object. In Table 5, the mapfile contains "libfoo. 
so - SUNW. 1.1". As shown in Table 4, application software "prog.c" references global symbols "fool " and "foo2". Symbol 
■'foo2" is defined in version SUNW.1.2. When prog.c is linked (using the cc compiler and ld(1) link-editor) with an -M 
option, it is linked only with version SUNW.1.1. Thus, as shown in Table 5, link-editor 124 identifies "foo2", which is 
defined in version SUNW.1 .2, as an undefined symbol. 

d. Promoting a Weak Version At Build Time 

[0059] Table 6 shows an example in which link-editor 124 is forced to "promote" a weak version (SUNW. 1.2.1) to a 
strong version. Because of the "-u" option, command line link-editor 124 records a dependency of "prog" on version 
SUNW.1 .2.1 in the version dependency section of "prog". Furthermore, "weak" flag 1116 is set to false for SUNW.1 .2.1 
in the version dependency section of "prog". In this case version SUNW.1 .2.1 inherits version SUNW.1 .2. Therefore, 
as all of prog's dependencies are "strong" Version reduction will mean that only SUNW.1 .2.1 is recorded in prog and 
that it will be recorded as non-weak. Promotion of a weak version ensures that runtime linker 126 will verify that the 
formerly weak version is present when "prog" is executed. 



$ cc -o prog prog.c -L. -R. -u SUNW.1.2.1 -Ifoo 

$pvs - r prog 

libfoo.so.1 (SUNW.1.2.1) 



TABLE 6 (Promotion of a weak version) 

3. Verifying Versioning Information at Runtime 

[0060] Fig. 15 is a flow chart 1500 showing steps performed by runtime linker 1 26 (see Fig. 2(d)) to insure that all 
required versions of referenced objects are present when linking and executing a dynamic executable object 1 20. The 
steps of Fig. 15 preferably are embodied by CPU 1 02 executing instructions stored in a memory. The steps of Fig. 15 
are performed as a pre-execution check to determine whether all required dependencies are present. 
[0061] In step 1502, linker 126 determines whether the dynamic executable object being executed contains a version 
dependency section (see Fig. 1 1 ). If not, no checking is done and normal execution continues. Otherwise, in step 1504. 
linker 126 determines whether at least one of the objects 114 being linked includes a version definition section and a 
version symbol section. If not, no further checking is done and normal execution continues. Otherwise control passes 
to step 1506. 

[0062] In step 1506, runtime linker 126 determines whether all version dependencies in the current dynamic execut- 
able object have been processed. If so, normal execution continues, otherwise control passes to step 1508. 
[0063] In step 1 508, runtime linker 1 26 determines whether a match exists between a needed version (as defined 
in the version dependency section of the dynamic executable 120) and the version definition section of the shared 
object 114. For example, in Figs. 16 and 1 8, version SUNW.1 .2 and SUNW.1 .2.1 are defined in the version definition 
section of shared object 1 1 4 and are specified as needed in the version dependency section of dynamic executable 1 20 . 
[0064] If a match is found in step 1508, then the needed version of object 114 is present and control returns to step 
1506. Otherwise, the needed version is not present and it is necessary to determine whether the missing version is a 
weak or a non-weak version in step 1510. Runtime linker 126 determines whether a version is weak by checking the 
"weak" flag 1116 in the version dependency section of dynamic executable 120. (Note that flag 1116 may reflect the 
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"promotion" of aversion from weak to strong). If, in step 1510, runtime linker 126 determines that the version is a weak 
version, no error occurs and control returns to step 1 506. Otherwise, a fatal error occurs because a needed, non-weak 
version is not present. Thus, a dependency on a missing "weak" version will not cause an error, but dependency on a 
missing "non-weak" version will. 

s [0065] Fig. 1 6 shows an example of a version definition section 1 600. Fig. 1 7 shows an example of a version symbol 
section 1700 for shared object 114 (libfoo.so.1 of Tables 1-3). Fig. 1 8 also shows an example of a version dependency 
section 1 800 forthe dynamical executable form of application program 120 ("prog" of Table 4). (In this example, shared 
object 14 has no dependencies on other objects, and so has no version dependency section). 
[0066] Fig. 1 6 contains a base version definition 1 604 and six version definitions for, respectively, versions SUNW. 

10 1.1, SUNW.1.2, SUNW.1.2.1, SUNW.1.3a, SUNW.1.3b, and SUNW.1 .4. Base version definition 1604 has its "base" 
flag set to "True". The version definition for SUNW.1 .2.1 has its "weak" flag set to "True". Each version definition has 
a respective (unique) version definition index. 

[0067] Version reduction is applied in the version definition table. Application "prog" references the global symbols 
fool (in SUNW.1 .1 ) and foo2 (in SUNW.1 .2). Because SUNW.1 .2 inherits the global symbols of SUNW.1 .1 , link-editor 
15 124 applies version reduction and an entry (for SUNW.1 .2) is made in version definition section. The weak version 
SUNW.1.2.1 is also recorded. 

[0068] Fig. 17 shows some of the symbols in version symbol section 1700. For example, the global variable "fool" 
is defined in version SUNW.1 .1 , which has aversion definition index of "2". Thus, the entry in the version symbol section 
corresponding to the entry in the symbol table for fool contains "2". In the described embodiment, the name for each 
20 version (e.g., SUNW.1 .1) is also a global symbol that is created when generating the version definition. 

[0069] Fig. 18 shows an example of a version dependency section in dynamic executable 120. Because of version 
reduction, the section contains an entry for SUNW.1 .2, but not for SUNW.1 .1 . The section also contains an entry for 
"weak" version SUNW.1 .2.1 . At runtime, linker 126 will determine that prog has a version dependency section (step 
1502), will determine that libfoo.so.1 has a version definition section (step 1504), and will determine that the needed 
version (SUNW.1 .2) is present (step 1 508). Therefore, "prog" will be executed. 

[0070] Several preferred embodiments of the present invention have been described. Nevertheless, it will be under- 
stood that various modifications may be made without departing from the scope of the invention as claimed. 
[0071] In describing the preferred embodiments, a number of specific technologies used to implement the embodi- 
ments of various aspects of the invention were identified and related to more general terms in which the invention was 
30 described. However, it should be understood that such specificity is not intended to limit the scope of the claimed 
invention. 



1. A method for providing versioning information in a software program, comprising the steps performed by a data 
processing system (100), of: 

providing first object code (112) for a first software program (110); 
40 providing a mapfile (130, 1 32), separate from the object code, specifying a version name associated with a 

version of the first software program, the mapfile (130, 132) further specifying global symbols that form an 
interface of the version of the first software program; and 

linking (124) the first object code (11 2), so that an addition is made to the first object code (112), in accordance 
with the mapfile (130, 132), of information identifying the version name of the first software program (110), to 
45 yield a versioned object (114), 

the linking step further including the step of adding information to the first object code (112), in accordance 
with the mapfile information, the information identifying the global symbols forming the interface of the version. 

2. The method of claim 1 , further comprising the steps of: 

50 

providing second object code (11 8) for a second software program (116); and 

linking the second object code (1 1 8) to the versioned object, wherein the linking step further includes the steps 
of: 

55 determining a version of the first software program (1 1 0) needed by the second software program (1 1 6), 

and 

adding to the second object code (118), information specifyingthe version needed by the second software 
program (116), to yield a dynamic executable program (120). 



13 

BNSDOCID: <EP 0752647B1_I_> 



EP 0 752 647 B1 



3. The method of claim 2, further comprising the steps of: 

prior to executing (f26) the dynamic executable program (120), determining whether the needed version in 
the dynamic executable program matches the version identified in the versioned object; and 
executing the dynamic executable program (120), wherein the dynamic executable program (120) calls the 
needed version of the versioned object. 

4. The method of claim 2, 

wherein the determining step further includes the step of determining a version of the first software program 
(110) needed by the second software program (116), by determining which global symbols are needed by the 
second software program (116) and determining, by checking the information in the versioned object, which ver- 
sions the needed global symbols are in. 

5. The method of claim 1 , wherein the information added to the first object code (112) is a version definition section 
(506). 

6. The method of claim 1 , wherein the information added to thef irst object code ( 1 1 2) is a version symbol section (508) . 

7. The method of claim 2, wherein the information added to the second object code )1 1 6) is a version dependency 
section (510). 

8. The method of claim 1 , wherein the versioned object (114) is a relocatable object. 

9. The method of claim 1 , wherein the versioned object is a dynamic executable object (1 20). 

10. The method of claim 1, wherein the versioned object (114) is a shared object. 

11. An apparatus for providing versioning information in a software program, comprising: 

a storage medium (1 04) holding object code for a first software program (110); 

a storage medium holding a mapfile (130, 132), separate from the object code (112), specifying a version 
name associated with a version of the first software program (110), the mapfile (1 30, 1 32) further specifying 
global symbols that form an interface of the version of the first software program (11 0); and 
a linker (124) configured to provide additional information in the first object code (112), in accordance with the 
mapfile (130, 132), the additional information defining the version name of the version of the first software 
program (110), to yield a versioned object (114), 

wherein the linker (124) is further configured to add information to the first object code (112), in accordance 
with the mapfile information, the information identifying the global symbols forming the interface of the version. 

12. The apparatus of claim 1 1 , further comprising: 

a storage medium holding second object code (118) for a second software program (116); and 
a linker configured to link the second object code (1 1 8) to the versioned object to yield a dynamic executable 
program (1 20), by adding additional information to the second object code (1 1 8) specifying the version needed 
by the second software program (116). 

13. The apparatus of claim 12, further comprising: 

a run-time linker (126) configured to provide execution of the dynamic executable program (120) if the run- 
time linker determines that the needed version specified in the dynamic executable program (120) matches 
the version defined in the versioned object, 

14. The apparatus of claim 11 , wherein the versioned object is a relocatable object (114). 

15. The apparatus of claim 11 , wherein the versioned object is a dynamic executable object (120). 

16. The apparatus of claim 11 , wherein the versioned object is a shared object. 
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17. A computer program product, comprising: 

a computer usable medium having computer readable code embodied therein for causing a determination that 
a version of an object required by a dynamic executable program (120) is present during execution of the 
dynamic executable program (120), the computer program product comprising: 

computer readable program code devices configured to cause a computer (1 02) to effect provision of first 
object code (112) for a first software program (110); 

computer readable program code devices configured to cause a computer to effect provision of a mapfile 
(130, 132), separate from the object code (112), specifying aversion name associated with a version of 
the first software program (110), the mapfile (130, 132) further specifying global symbols that form an 
interface of the version of the first software program (110); and 

computer readable program code devices configured to cause a computer to effect linking the first object 
code (112), so that an addition is made to the first object code (112), in accordance with the mapfile (130, 
132), of information identifying the version name of the version of the first software program, to yield a 
versioned object (114), and further configured to add information to the first object code (112), in accord- 
ance with the mapfile information, the information identifying the global symbols forming the interface of 
the version. 

18. The computer program product of claim 1 7, further comprising: 

computer readable program code devices configured to cause a computerto effect provision of second object 
code (11 8) for a second software program (116); and 

computer readable program code devices configured to cause a computer to effect linking the second object 
code (118) to the versioned object, by determining a version of the first software program (110) needed by the 
second software program (116), and adding to the second object code (118), information specifying the version 
needed by the second software program (116), to yield a dynamic executable program (120). 

19. The computer program product of claim 1 8, further comprising: 

computer readable program code devices configured to cause a computer to effect a determination of whether 
the version needed by the dynamic executable program (120) to effect execution of program matches the 
version defined in the versioned object (114); and configured to execute the dynamic executable program, 
wherein the dynamic executable program (120) calls the needed version of the versioned object (114). 



Patentanspriiche 

1. Verfahren zur Bereitstellung einer Versionsbildungsinformation in einem Softwareprogramm mit den folgenden 
Schritten, die von einem Datenverarbeitungssystem (100) durchgefuhrt werden: 

Vorsehen eines ersten Objektcodes (112) fur ein erstes Softwareprogramm (110); 

Vorsehen einer Abbildungsdatei (130, 132) separat vom Objektcode, welche einen Versionsnamen festlegt, 
der einer Version des ersten Softwareprogramms zugeordnet ist, wobei die Abbildungsdatei (130, 132) ferner 
globale Symbole festlegt, die eine Schnittstelle der Version des ersten Softwareprogramms bilden; und 
Verkniipfen (124) des ersten Objektcodes (112), so da3zum ersten Objektcode (112) gemaB der Abbildungs- 
datei (130, 132) eine Information hinzugefugt wird, die den Versionsnamen des ersten Softwareprogramms 
(110) identifiziert, urn ein Versionsobjekt (114) zu ergeben, 

wobei der Verknupfungsschritt ferner den Schritt des Hinzufiigens einer Information zum ersten Objektcode 
(112) gemaB der Abbildungsdateiinformation umfaBt, wobei die Information die globalen Symbole identifiziert, die 
die Schnittstelle der Version bilden. 

2. Verfahren nach Anspruch 1 , welches ferner die Schritte umfaBt: 

Vorsehen eines zweiten Objektcodes (118) fiirein zweites Softwareprogramm (116); und 

Verkniipfen des zweiten Objektcodes (1 1 8) mit dem Versionsobjekt, wobei der Verknupfungsschritt ferner die 

Schritte umfaBt: 
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Feststellen einer Version des ersten Softwareprogramms (110), die fur das zweite Softwareprogramm 
(116) erforderlich ist, und 

Hinzufiigen einer Information zum zweiten Objektcode (118), die die Version festlegt, die fur das zweite 
Softwareprogramm (116) erforderlich ist, urn ein dynamisches ausfiihrbares Programm (120) zu ergeben. 

3. Verfahren nach Anspruch 2, welches ferner die Schritte umfaSt: 

vor dem Ausfiihren (126) des dynamischen ausfiihrbaren Programms (120) Feststellen, ob die erforderliche 
Version im dynamischen ausfiihrbaren Programm der Version entspricht, die im Versionsobjekt identifiziert 
<° Ist; und 

Ausfuhren des dynamischen ausfiihrbaren Programms (120), wobei das dynamische ausfiihrbare Programm 
(120) die erforderliche Version des Versionsobjekts aufruft. 

4. Verfahren nach Anspruch 2, 

15 wobei der Feststellungsschritt ferner den Schritt des Feststellens einer Version des ersten Softwarepro- 

gramms (110) umfaBt, die fur das zweite Softwareprogramm (116) erforderlich ist, durch Feststellen, welche glo- 
balen Symbole fur das zweite Softwareprogramm (116) erforderlich sind, und durch Feststellen, durch Priifen der 
Information im Versionsobjekt, in welchen Versionen sich die erforderlichen globalen Symbole befinden. 

20 5. Verfahren nach Anspruch 1, wobei die zum ersten Objektcode (112) hinzugefiigte Information ein Versionsdefini- 
tionsabschnitt (506) ist. 

6. Verfahren nach Anspruch 1 , wobei die zum ersten Objektcode (112) hinzugefiigte Information ein Versionssym- 
bolabschnitt (508) ist. 

25 

7. Verfahren nach Anspruch 2, wobei die zum zweiten Objektcode (116) hinzugefiigte Information ein Versionsab- 
hangigkeitsabschnitt (510) ist. 

8. Verfahren nach Anspruch 1 , wobei das Versionsobjekt (114) ein relativierbares Objekt ist. 

30 

9. Verfahren nach Anspruch 1 , wobei das Versionsobjekt ein dynamisches ausfiihrbares Objekt (120) ist. 

10. Verfahren nach Anspruch 1, wobei das Versionsobjekt (114) ein gemeinsam genutztes Objekt ist. 

35 11. Vorrichtung zur Bereitstellung einer Versionsbildungsinformation in einem Softwareprogramm, umfassend: 

ein Speichermedium (104), das einen Objektcode fiir ein erstes Softwareprogramm (110) speichert; 
ein Speichermedium, das eine Abbildungsdatei (130, 132) separat vom Objektcode (112) speichert, welche 
einen Versionsnamen festlegt, der einer Version des ersten Softwareprogramms (110) zugeordnet ist, wobei 
40 die Abbildungsdatei (130,1 32) ferner globale Symbole festlegt, die eine Schnittstelle der Version des ersten 

Softwareprogramms (110) bilden; und 

ein Binderprogramm (124), das dazu ausgelegt ist, eine zusatzliche Information im ersten Objektcode (112) 
gemaB der Abbildungsdatei (130, 132) vorzusehen, wobei die zusatzliche Information den Versionsnamen 
der Version des ersten Softwareprogramms (110) festlegt, urn ein Versionsobjekt (11 4) zu ergeben, 

45 

wobei das Binderprogramm (124) ferner dazu ausgelegt ist, eine Information zum ersten Objektcode (112) 
gemaB der Abbildungsdateiinformation hinzuzufugen, wobei die Information die globalen Symbole identifiziert, die 
die Schnittstelle der Version bilden. 

so 12. Vorrichtung nach Anspruch 1 1 , welche ferner umfaBt: 

ein Speichermedium, das einen zweiten Objektcode (118) fiir ein zweites Softwareprogramm (1 1 6) speichert; 
und 

ein Binderprogramm, das dazu ausgelegt ist, den zweiten Objektcode (118) mit dem Versionsobjekt zu ver- 
55 kniipfen, urn ein dynamisches ausfiihrbares Programm (1 20) zu ergeben, durch Hinzufiigen einerzusatzlichen 

Information zum zweiten Objektcode (118), der die Version festlegt, die fiir das zweite Softwareprogramm 
(116) erforderlich ist. 
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13. Vorrichtung nach Anspruch 12, welche ferner umfaBt: 



ein Laufzeit-Binderprogramm (126), das dazu ausgelegt ist, eine Ausfiihrung des dynamischen ausfuhrbaren 
Programms (120) vorzusehen, wenn das Laufzeit-Binderprogramm feststellt, da(3 die erforderliche Version, 
die im dynamischen ausfuhrbaren Programm (1 20) festgelegt ist, der Version entspricht, die im Versionsobjekt 
festgelegt ist. 



14. Vorrichtung nach Anspruch 11, wobei das Versionsobjekt ein relativierbares Objekt (114) ist. 



15. Vorrichtung nach Anspruch 11 , wobei das Versionsobjekt ein dynamisches ausfiihrbares Objekt (1 20) ist. 

16. Vorrichtung nach Anspruch 11 , wobei das Versionsobjekt ein gemeinsam genutztes Objekt ist. 

17. Computerprogrammprodukt mit: 

einem vom Computer verwendbaren Medium mit einem darin verkorperten maschinenlesbaren Code zum 
Veranlassen einer Feststellung, daB eine Version eines Objekts, die fur ein dynamisches ausfuhrbares Pro- 
gramm (120) erforderlich ist, wahrend der Ausfiihrung des dynamischen ausfuhrbaren Programms (120) vor- 
liegt, wobei das Computerprogrammprodukt umfaBt: 



Vorrichtungen fur einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer 
(1 02) zu veranlassen, die Bereitstellung eines ersten Objektcodes (112) fur ein erstes Softwareprogramm 
(110) zu bewirken; 

Vorrichtungen fur einen maschinenlesbaren Programmcode, die dazu ausgelegt slnd, einen Computerzu 
veranlassen, die Bereitstellung einer Abbildungsdatei (130, 132) separat von dem Objektcode (112) zu 
bewirken, welche einen Versionsnamen festlegt, der einer Version des ersten Softwareprogramms (110) 
zugeordnet ist, wobei die Abbildungsdatei (130, 1 32) ferner globale Symbole festlegt, die eine Schnittstelle 
der Version des ersten Softwareprogramms (110) bilden; und 

Vorrichtungen fur einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computerzu 
veranlassen, eine Verkniipfung des ersten Objektcodes (1 12) zu bewirken, so daB zum ersten Objektcode 
(112) gemaB der Abbildungsdatei (130, 132) eine Information hinzugefugt wird, die den Versionsnamen 
der Version des ersten Softwareprogramms identifiziert, urn ein Versionsobjekt (114) zu ergeben, und 
ferner dazu ausgelegt sind, eine Information zum ersten Objektcode (112) gemaB der Abbildungsdatei- 
information hinzuzufugen, wobei die Information die globalen Symbole identifiziert, die die Schnittstelle 
der Version bilden. 



18. Computerprogrammprodukt nach Anspruch 17, welches ferner umfaBt: 



Vorrichtungen fur einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu 
veranlassen, die Bereitstellung eines zweiten Objektcodes (118) fur ein zweites Softwareprogramm (116) zu 
bewirken; und 

Vorrichtungen fur einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu 
veranlassen, die Verkniipfung des zweiten Objektcodes (118) mit dem Versionsobjekt zu bewirken, durch 
Feststellen einer Version des ersten Softwareprogramms (110), die fur das zweite Softwareprogramm (116) 
erforderlich ist, und durch Hinzufugen einer Information zum zweiten Objektcode (118), die die Version festlegt, 
die fur das zweite Softwareprogramm (116) erforderlich ist, urn ein dynamisches ausfuhrbares Programm 
(120) zu ergeben. 



19. Computerprogrammprodukt nach Anspruch 18, welches ferner umfalSt: 

Vorrichtungen fur einen maschinenlesbaren Programmcode, die dazu ausgelegt sind, einen Computer zu 
veranlassen, eine Feststellung dessen zu bewirken, ob die Version, die fur das dynamische ausfiihrbare Pro- 
gramm (120) erforderlich ist, urn die Ausfiihrung des Programms zu bewirken, der Version entspricht, die im 
Versionsobjekt (114) festgelegt ist; und dazu ausgelegt sind, das dynamische ausfiihrbare Programm auszu- 
fiihren, wobei das dynamische ausfiihrbare Programm (120) die erforderliche Version des Versionsobjekts 
(114)aufruft. 
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Revendications 

1. Precede destine a fournir des informations de version dans un programme de logiciel, comprenant les etapes 
executees par un systeme detraitement de donnees (100), consistant a: 

5 

fournir un premier code objet (112) pour un premier programme de logiciel (110), 

fournir un fichierd'implantation (130, 132), separe du code objet, specifiant un nom de version associea une 
version du premier programme de logiciel, le fichierd'implantation (130, 132) specifiant en outre des symboles 
globaux qui forment une interface de la version du premier programme de logiciel, et 
10 lier (124) le premier code objet (112), de maniere a ce qu'une addition soit faite au premier code objet (112), 

conformement au fichier d'implantation (130, 132), d'informations identifiant le nom de version du premier 
programme de logiciel (110), afin de produire un objet a version definie (114), 

I'etape de liaison comprenant en outre I'etape consistant a ajouter des informations au premier code objet 
(112), conformement aux informations du fichier d'implantation, les informations identifiant les symboles glo- 
15 baux formant I'interface de la version. 

2. Precede selon la revendication 1 , comprenant en outre les etapes consistant a: 

fournir un second code objet (118) pour un second programme de logiciel (116), et 
20 lier le second code objet (1 1 8) a I'objet a version definie, dans lequel I'etape de liaison comprend en outre les 

etapes consistant a: 

determiner une version du premier programme de logiciel (110) necessaire au second programme de 
logiciel (116), et 

25 ajouter au second code objet (118) des informations specifiant la version necessaire au second program- 

me de logiciel (116), afin de produire un programme dynamique executable (120). 

3. Precede selon la revendication 2, comprenant en outre les etapes consistant a: 

30 avant d'executer (126) le programme dynamique executable (120), determiner si la version necessaire dans 

le programme dynamique executable correspond a la version identifiee dans I'objet a version definie, et 
executer le programme dynamique executable (120), dans lequel le programme dynamique executable (120) 
appelle la version necessaire de I'objet a version definie. 

3s 4. Precede selon la revendication 2, 

dans lequel I'etape de determination comprend en outre I'etape consistant a determiner une version du pre- 
mier programme de logiciel (110) necessaire au second programme de logiciel (116), en determinant quels sym- 
boles globaux sont necessaires au second programme de logiciel (116), et en determinant, par la verification des 
informations dans I'objet a version definie, dans quelles versions se trouvent les symboles globaux necessaires. 

40 

5. Precede selon la revendication 1, dans lequel les informations ajoutees au premier code objet (112) representent 
une section de definition de version (506). 

6. Precede selon la revendication 1 , dans lequel les informations ajoutees au premier code objet (112) representent 
4S une section de symbole de version (508). 

7. Precede selon la revendication 2, dans lequel les informations ajoutees au second code objet (116) representent 
une section de dependance de version (510). 

so 8. Precede selon la revendication 1 , dans lequel I'objet a version definie (114) est un objet translatable. 

9. Precede selon la revendication 1 , dans lequel I'objet a version definie est un objet dynamique executable (120). 

10. Precede selon la revendication 1 , dans lequel I'objet a version definie (114) est un objet partage. 

55 

11. Dispositif destine a fournir des informations de version dans un programme de logiciel, comprenant : 

un support de memorisation (104) contenant un code objet pour un premier programme de logiciel (110), 
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un support de memorisation contenant un fichier d 1 implantation (130, 132), separe du code objet (112), spe- 
cif iantun nomde version associe a une version du premier programme de logiciel (110), le fichier d'implantation 
(130, 132) specifiant en outre des symboles globaux qui torment une interface de la version du premier pro- 
gramme de logiciel (110), et 

un editeurde liens (124) configure pour fournir des informations supplementaires dans le premier code objet 
(112), conformement au fichier d'implantation (130, 132), les informations supplementaires definissantle nom 
de version de la version du premier programme de logiciel (110), afin de produire un objet a version definie 
(114), 

dans lequel I'editeur de liens (124) est en outre configure pour ajouter des informations au premier code 
objet (112), conformement aux informations du fichier d'implantation, les informations identifiant les symboles 
globaux formant I'interface de la version. 



12. Dispositif selon la revendication 11 , comprenant en outre : 

15 

un support de memorisation contenant un second code objet (1 1 8) destine a un second programme de logiciel 
(116), et 

un editeur de liens configure pour lier le second code objet (11 8) a I'objet a version definie afin de produire un 
programme dynamique executable (120), en ajoutant des informations supplementaires au second code objet 
20 (118) specifiant la version necessaire au second programme de logiciel (116). 



13. Dispositif selon la revendication 12, comprenant en outre : 



un editeurde liens d'execution (126) configure pour permettre I'execution du programme dynamique execu- 
25 table (120) si I'editeur de liens d'execution determine que la version necessaire specifiee dans le programme 

dynamique executable (120) correspond a la version definie dans I'objet a version definie. 

14. Dispositif selon la revendication 11 , dans lequel I'objet a version definie est un objet translatable (114). 

30 15. Dispositif selon la revendication 11, dans lequel I'objet a version definie est un objet dynamique executable (120). 

16. Dispositif selon la revendication 11 , dans lequel I'objet a version definie est un objet partage. 

17. Produit de programme informatique, comprenant : 

35 

un support utilisable par un ordinateur comprenant un code lisible par un ordinateur incorpore dans celui-ci 
afin de provoquer une determination de ce qu'une version d'un objet requis par un programme dynamique 
executable (120) est presente durant I'execution du programme dynamique executable (120), le produit de 
programme informatique comprenant : 



des dispositifs de codes de programme lisibles par un ordinateur configures pour amener un ordinateur 
(102) a activer lafourniture du premier code objet (112) pour un premier programme de logiciel (110), 
des dispositifs de codes de programme lisibles par un ordinateur configures pour amener un ordinateur 
(102) a activer la fourniture d'un fichier d'implantation (130, 132), separe du code objet (112), specifiant 
un nom de version associe a une version du premier programme de logiciel (110), le fichier d'implantation 
(130, 132) specifiant en outre des symboles globaux qui forment une interface de la version du premier 
programme de logiciel (110), et 

des dispositifs de codes de programme lisibles par un ordinateur configures pour amener un ordinateur 
a activer la liaison du premier code objet (112), de sorte qu'une addition soitfaite au premier code objet 
(112), conformement au fichier d'implantation (130, 132), d'informations identifiant le nom de version de 
la version du premier programme de logiciel, afin de produire un objet a version definie (1 1 4) et configures 
en outre pour ajouter des informations au premier code objet (112), conformement aux informations du 
fichier d'implantation, les informations identifiant les symboles globaux formant i'interface de la version. 



18. Produit de programme informatique selon la revendication 17 comprenant en outre 



des dispositifs de codes de programme lisibles par un ordinateur configures pour amener un ordinateur a 
activer la fourniture du second code objet (118) pour un second programme de logiciel (116), et 
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des dispositifs de codes de programme lisibles par un ordinateur configures pour amener un ordinateur a 
activer la liaison du second code objet (11 8) a I'objet a version, definie, en determinant une version du premier 
programme de iogiciel (1 1 0) necessaire au second programme de logiciel (110) et en ajoutant au second code 
objet (118) des informations specifiant la version necessaire au second programme de logiciel (116), afin de 
s produire un programme dynamique executable (120). 

19. Produit de programme informatique selon la revendication 1 8 comprenant en outre : 

des dispositifs de codes de programme lisibles par un ordinateur configures pour amener un ordinateur a 
10 realiser une determination de ce que la version necessaire au programme dynamique executable (120) pour 

activer I'execution du programme correspond a la version definie dans I'objet a version definie (114), et con- 
figures pourcxecuter le programme dynamique executable dans lequel le programme dynamique executable 
(120) appelle la version necessaire de I'objet a version definie (114). 

15 
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100 




Relocatable 
for shared 



*Vii 



114^ 

Hbc \ 
Shared object 
(includes a version 
definition section, a 
version symbol section 
and possibly a version 
Jon.) 



122 



Source for 
application 



Relocatable 
for 



116 



118 



120 



Dynamic 
executable 

tor 
application 
(includes a 



dependency 
section.) 



124 126 



Mapfile(s) 



130 132 



Fig. 1 
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Mapflle 
(Has «« version* of the 
- relocatable object «nd s 
meiffllotal symbols) 



112 



(Tor shared object) 




Fig. 2(a) 



114 i 

Shared object 
(contains a version 



section, and possibly a 



'' w Relocatable object 

1 (to application) [ \ . 

snared object / I 



Fig. 2(b) 



> 



Build 
environment 




<^ Suild 
i environniem 



Fig. 2(d) 
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Link editor invoked with « G 
option (produces shared 

object) and • M option (uses 
mapfiie as link directive) 




306- 



Create a base 
version definition for 
object (in version 
definition section) 
(set *base' flag) 



see fig. 3(b) 



| Create a version 
; definition for each 
> version of object fin 

version definition 
! section) : 



see fig. 3(b) 



ate a version symbol section for 
symbols of object (local, base, and 
global symbols) (perform symbol 



Create a version 
dependency section 
fif this object depends 
on other versioned 



Fig. 3(a) 

Link-Editor Creates Version Definition 
Section and Version Symbol Section 
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[<version name>] { 
[<scope>:] 

[<syrobol<s)>]; 

} [inheritance information^ ; 



Fig. 4 

Format of link directives 
(version definitions) (in mapfile) 
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ELF header 



Section 1 



Version definition 
section 



Version symbol 
section 



Version dependency 
section (optional) 



Section n 



Section header table 



^502 
^504 



\ 5 06 
\ version definition information 

"VS08 

fit 



version dependency information 
^510 



\512 



^514 



Fig. 5 

ELF Object File Format 
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506 



A version definition / 
(one for each version of <^ 
the object) 



One for the name of the I 
version itself and one J 
for each version S 
that is inherited 




Version definition index \ 610 
\ 612 



Section header 



Structure version 



Count 



6J>2 
604 



Hash 



Next version 
definition 



Name of version 



X 614 

V 616 

V 618 
X 620 

V 622 



Fig. 6 

Version Definition Section Format 
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508 



Same index 
as symbol table 



# entries in 
symbol table 



Section header 



Version def index 
for symbol #1 



Version def index 
for symbol #2 



Version def index 
for symbol #m 



V02 
*Vo4 

^•704 



| 0 = symbol has local scope 

version def index J 1 s symbol has global scope and 
A is in base version definition 

>1 - symbol has global scope (assigned to user - 
^- defined version definition) 

(see version definition index - 610) 



Fig. 7 

Version Symbol Section forme! 
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810 I 

■ ^ 1 

I Record required 
t dependencies of this 
object in its version 
dependency section 

only if those 
dependencies are 
indicated in the link 
directive (perform 
version definition 

reduction to 
normalize inherited 
dependencies) 



806 

S 

^Do link directives limit which^v 

versions of the versioned ;> 
^object^an be depended on?/' 

/ 

N *» 



Record all required dependencies of this 
object in its version dependency section 
(perform version definition reduction to 
normalize inherited dependencies) 



Fig. 8 

Link-Editor Creates Version 
Dependency Section 
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<objectname> - <version(s)>; 



Fig. 9 

Format of link directives 
(version control directives) 
(in mapfiie) 
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1000 



ELF header 



Program header 



Section 1 



Version dependency ! 
section | 



Section N 



Section header table 
(optional) 



Fig. 10 

ELF Object File (a 
dynamic executable) 
output from link-editor) 
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510 



One for 
each 

needed 
version of 
an object 



,< 



One for each 

needed J 
version and S 
one for each 
weak version 



Section header 



Structure version 



Count 



*^11G2 
^-1104 
^1106 



Filename of needed object ! *v. 1 f08 

section j^1112 
1^1114 



Aux 

Next version dependency 



Hash 



Unused 



Unused 
Name of "depended on* 



(needed) version 



Weak ■ ^ flags "V 1116 

— ; — 

i~Ml18 
""M120 



'^1122 



Fig. li 

Version Dependency Section Format 
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Section header format 



typedef struct { 

Elf32_Word srwiame; — -1202 

Elf32_Word shjype; ^204 

Elf32J/Vord sh flags; 

Elf32_Addr srTaddn 

Elf32_Off sh_offset; 

Elf32_Word sh_size; ——1306 

Etf32_Word shjink; — 1308 

Elf32_Word shjnfo; 1310 

Elf32_Word sh_addralign; 

Elf32_Word sh_entsize; 
} Elf32_Shdn 



Fig. 12 
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Section Types, sh_type 
Name Value 



SHT.NULL 

SHT PROGBITS 

SHT.SYMTA8 

SHT STRTAB 

SHT_RELA 

SHT.HASH 

SHT.DYNAMIC 

SHTJMOTE 

SHT NOBITS 

SHT_REL 

SHT SHLIB 

shTdynsym 

SHT_SUNW vertfef 

SHT_SUNWj/erneed 

SHTSUNW versym 

SHT LOPROC 

SHT.HIPROC 

SHTJ.OUSER 

SHTHIUSER 



0 
1 
2 
3 
4 
5 
6 
7 
8 
9 

10 
11 

OxSffffffd 

OxQffffffe 

0x6fffffff 

0x70000000 

0x7fflffif 

0x80000000 

Oxffffffff 



Fig. 13 
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shjink an 


d stTinfo Interpretation 




shjype 


shjink 


shjnfo . 


SHT.OYNAMIC 


The section header index of 
the associated strino table. 


0 


SHT.HASH 


The section header index of 
the associated symbol table. 


0 


SHT.REL 
SHT.REIA 


The section header index of. 
• the associated symbol table. 


The section header index of 
the section to which the 
relocation applies. 


SHT SYMTAB 
SHTJ3YNSYM 


The section header index of 
the associated string table. 


One greater than the symbol 
table index of the last local 
symbol (binding STBJ.OCAL). 


SHT_SUNW_verdQf 


The section header index of 
the associated string table. 


The number of version ' 
definitions within the section. 


SHT_SUNW_vemeed 


The section header index of the 
associated string table. 


The number of version 
dependencies within the 
section. 


SHT_SUNW_versym 


The section header index of 
the associated symbol 
table. 


0 


other ' 


SHNJJNDEF 


0 



Fig. 14 
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1502 



1500 



Is there a version^ 
^dependency section (KstO 




1512 

s 


Fatal error 











Fig. 15 

Runtime Verification 
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Fig.. 16 
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1700 



Version Symbol 
Section (for 
libfoo.so.1) 



Symbol Table {for 
libfoo.sb.1) 



Fig. 17 
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1800 

\ 



0 



hash value for 
SUNW.1.2 



nime ol dependent 

versions 
gUNW.1,3 



hash value for 

SUNW.1J.1 



name ot aepenaem 
version * 

SUNW1.?1 



Fig. 18 

Version Dependency Section 



